BlazeDS Developer Guide

Monitoring and managing services

BlazeDS uses Java Management Beans (MBeans) to provide run-time monitoring and management of the services configured in the services configuration file. The run-time monitoring and management console is an example of a Flex client application that provides access to the run-time MBeans. The application calls a Remoting Service destination, which is a Java class that makes calls to the MBeans.

About the run-time monitoring and management console

The run-time monitoring and management console is a Flex client application that provides access to the run-time MBeans in the data services web applications running on an application server. The console application calls a Remoting Service destination, which is a Java class that makes calls to the MBeans.

The console is in the ds-console web application; you run it by opening http://server:port/ds-console when the web application is running, where server:port contains your server and port names.

The tabs in the console provide several different views of run-time data for the data service applications running in the application server. You use the Application combobox to select the web application you want to monitor. You can use a slider control to modify the frequency with which the console polls the server for new data.

The general administration tab provides a hierarchical tree of all the MBeans in the selected web application. Other views target specific types of information. For example, tabs provide server, channel endpoint, and destination information. These tabs include dynamic data graphs for applicable properties.

One log manager tab shows the log categories set in the services-config.xml file and lets you add or remove log categories at run time. You change the log level (debug, info, warn, and so forth) for the log categories. For information about logging, see Server-side logging.

Note: The run-time monitoring and management console exposes administrative functionality without authorization checks. Deploy the ds-console web application to the same application server that your Flex web application is deployed to, and lock down the ds-console web application by using J2EE security or some other means to protect access to it. For more information about J2EE security, see your application server documentation and http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security.html.

MBean creation and registration

The APIs exposed by the run-time MBeans do not affect or interact with the BlazeDS configuration files. You can use them for operations such as ending a stale connection or monitoring message throttling, but you cannot use them for operations such as registering a new service or altering the settings for an existing server component.

The run-time MBeans are instantiated and registered with the local MBean server by their corresponding managed resource. For example, when a MessageBroker is instantiated, it creates and registers a corresponding MessageBrokerControlMBean with the MBean server. The underlying resource sets the attributes for the run-time MBeans and they are exposed in a read-only manner by the MBean API. In some cases, an MBean can poll its underlying resource for an attribute value.

MBean naming conventions

The run-time MBean model starts at the MessageBrokerControlMBean. You can traverse the model by using attributes on MBeans that reference other MBeans. For example, to access an EndpointControlMBean, you start at the MessageBrokerControlMBean and get the Endpoints attribute. This attribute contains the ObjectNames of all endpoints that are registered with the management broker. It lets any management client generate a single ObjectName for the root MessageBrokerControlMBean, and from there, navigate to and manage any of the other MBeans in the system without having their ObjectNames.

The run-time MBean model is organized hierarchically; however, each registered MBean in the system has an MBean ObjectName and can be fetched or queried directly if necessary. The run-time MBeans follow ObjectName conventions to simplify registration, lookup, and querying. An ObjectName for an MBean instance is defined as follows:

{domain}:{key}={value}[,{keyN}={valueN}]*

You can provide any number of additional key-value pairs to uniquely identify the MBean instance.

All of the run-time MBeans belong to the flex.run-time domain. If an application name is available, it is also included in the domain as follows: flex.runtime.application-name.

Each of the run-time MBean ObjectNames contains the following keys:

Key

Description

type

Short type name of the resource managed by the MBean. The MessageBrokerControlMBean manages the flex.messaging.MessageBroker, so its type is MessageBroker.

id

The id value of the resource managed by the MBean. If no id is available on the resource, an id is created according to this strategy:

id = {type} + N

where N is a numeric increment for instances of this type.

An ObjectName can also contain additional optional keys.

The run-time MBeans are documented in the public BlazeDS Javadoc documentation. The Javadoc also includes documentation for the flex.management.jmx.MBeanServerGateway class, which the run-time monitoring and management console uses as a Remoting Service destination.


 

Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/blazeds/1/blazeds_devguide/services_logging_4.html