Feature

AJAX and JMX are at opposite ends of the Systems Management stack. However, the emerging ubiquity of the AJAX model for rich browser clients has obscured the benefits the model provides in the architectural space for enhancing support patterns within the problem resolution pipeline.

This article elaborates on an architectural benefit of AJAX that lets the management state be 'broadcast' to a browser-enabled user base without waiting for a page refresh.

This architecture is an extension of a general pattern for logging JMX events and properties to a server-side log file; this variation logs or 'broadcasts' management information to the (AJAX-enabled) user base.

Emphasis is placed on the AJAX request/response model and the painting of management data to the page, together with the beautiful JMX notification framework, all neatly integrated in the middle with an instrumented servlet.

Also included is a cursory view of issues not usually covered in the standard AJAX discussion; namely, security and capacity models.

BEA WebLogic 8.1 was used as the deployment platform for the software, although the architecture and method applies to other J2EE application servers.

Key Requirements
The Systems Management stack for Enterprise Java and J2EE applications forms part of the problem resolution pipeline in which the Java/J2EE application interacts with a management tier to monitor potential problems such as application server thread starvation, heap overflow or stale connections to a database.

The management tier usually consists of JMX MBeans, which the application is instrumented to use, together with products such as Wily Introscope to read these JMX properties, and HP OpenView, which can be alerted from Wily if a configured threshold is violated.

One problem with this model is that server-side patterns for JMX management don't help the client at the browser if the system is going down behind him; it's all server-centric. For example, if a new J2EE Web application is to be deployed, or the application is to shut down in a few minutes because Wily has detected a problem, the user at the browser is unaware of management events that are imminent.

By gracefully allowing the user into the problem resolution pipeline, the systems administrator can manage the end-user experience to his advantage by broadcasting management information to the user base and to some extent control the user's behavior.

To communicate management information to clients over HTTP, a problem exists: how can the management aspect send management information to an HTTP client if the user at the client doesn't overtly refresh the page using GET or POST, and if the client doesn't covertly refresh a hidden frame?

Solution Description
Implementing a simple AJAX script that will take management information in the form of an XML message from the MBean server via a servlet solves the problem. This management information must be administered and fed to all participating application servers that can receive AJAX requests.

On the server side:

• A cluster of J2EE application servers is used to service requests from browser-based users, the on-line transaction processing (OLTP) user-base (two or four servers, for example). User requests are load-balanced across this cluster (OLTP cluster) using a third-party Web server.
• A standard MBean (UserWeb) is used to hold management information, e.g., administration message plus metadata properties. The MBean is hosted on both the J2EE 'administration' server and the remaining J2EE servers in the OLTP cluster.
• On the administration server, a system administrator uses the HTMLAdaptor for JMX to set the alert status, retry interval (the interval between XMLHttp-Requests), and alert message; for example, 'System Down in 10 Minutes.' The administrator then broad-casts this state to the MBeans on the managed servers, which reset their state to the master administration state.

  On the client side:

• AJAX-enabled clients retrieve the status, retry interval, and message using an XMLHttpRequest, which invokes a servlet to return the relevant MBean values as an XML message.
• JavaScript on the client then parses this XML message, resets the retry interval, and repaints a part of the screen with the management message.
• After retry-interval seconds, the client does another XMLHttpRequest and the client cycle begins again.

Essential Architecture
Figure 1 shows the overall solution architecture. The essential architecture elements are described in Table 1- Architecture Elements.

JMX Notification Model
This model involves two components:

• MBean to raise events for registered listeners, both local and remote
• Listeners, which register themselves with the MBean to listen for events generated by that MBean

The first is implemented by the UserWeb MBean, the second by the ManagementListener.

JMX MBean for Managing User Information
The UserWeb standard MBean is a simple class that contains key properties and methods as shown in Table 2 - UserWeb MBean Properties and Methods.

Event Listener
The Singleton ManagementListener class implements Weblogic.management.RemoteNotificationListener, which extends javax.management.NotificationListener and java.rmi.Remote to allow events in a remote WebLogic JVM to be notified of remote listeners using RMI.

At application server start-up, a listener on each JVM registers itself with the UserWeb MBean on the administration server.

MBean Helper
It's best practice to use a helper class as a façade for Mbeans.This helper is invoked from instrumented code to call MBean methods.

The UserWebMBeanHelper class is used as the façade for the UserWeb MBean. The ancestor of all helpers is ApplicationMBeanHelper, which:

• Looks up the local and remote MBean servers
• Invokes those servers to get/set MBean properties and invoke MBean methods

To ensure parity, both the MBean and MBean helper implement the interface UserWebMBean.

Instrumented Servlet
An application is instrumented to use JMX. In AOP terms, the management aspect is woven into the application code. The first JMX instrumentation point for this article is an HTTPServlet. This servlet is the target of the AJAX request and implements a controller pattern that can be elaborated down to handle other AJAX requests using simple request parameters.

From an MVC perspective, the model is the UserWeb Mbean, the view is the AJAX-enabled (JSP) page, and the controller is the instrumented servlet.

Client AJAX Engine
This is a set of JavaScript functions that:

• Manage the XMLHttpRequest and response processing iterations
• Parse the XML message returned by the XMLHttpRequest
• Repaint the screen with the XML message contents

Client Presentation
This is the main.jsp page that contains the client AJAX engine and repaintable section.

Sequence in Action
Essentially, the server sequence is concerned with managing the setting of the management properties and broadcasting these properties to all interested (listening) JVMs. The client sequence is concerned with retrieving these properties and repainting the HTML page with important management information at management-specified intervals.

JMX Notification (Server Sequence)

• UserWeb MBeans and MBean event listeners are created and registered at application server start-up using start-up classes
• The administrator sets the 'master' UserWeb MBean properties (alert message and retry interval), then broadcasts, or notifies, this state to the listeners hosted on the remote managed servers
• The remote listeners handle the notification by copying the master (notification) data to the local UserWeb MBean

XMLHttpRequest Poll (Client Sequence)

• AJAX-enabled clients invoke a servlet at intervals to query management state
• The servlet reads the local UserWeb MBean properties, inserts them into an XML message, and returns the XML message as an XML response to the browser client (alternative message formats are discussed later)
• The AJAX client then parses the XML document, extracts the alert message and retry interval, repaints the screen, and then uses the retry interval to set the delay for the next XMLHttpRequest