You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

The purpose of this article is to show the possibilities of server-side monitoring using Geronimo, a JavaTM 2 Platform Enterprise Edition (J2EE) application server. Monitoring an application server from inside saves network traffic, since monitored information can be analyzed, filtered, summarized, and set into an application specific context inside the server. For example an application server could send an e-mail when the response time of our online shop gets unacceptable big. A simple web application has been used to develop a server-side monitoring component that monitors three servlets and gives alarm when the overall average processing time exceeds a certain given threshold.

What is needed

Introduction

A lot of articles can be found in managing application servers with remote clients using the Java Management Extensions (JMX; http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/). These management client applications describe how to connect management clients to a server and how to retrieve information from the server applications. While much attention has been given to the client-side aspects of JMX, very little consideration has been given to the server-side challenges of developing and deploying management beans (MBeans). The reason lays in the difficulties of development and integration of such components. Often it is not possible at all. With the appearance of Geronimo the server-side monitoring by implementing MBeans for monitoring servlets or EJBs is simplified.

This article shows how to monitor the application server Geronimo from inside and how detailed information querying the MBeans can be analyzed, grouped and generated to meta data inside the server. This saves bandwidth between the management client and the server and allows to build a more efficient controlled application server with the monitor component inside.

To keep it simple the Geronimo monitoring component is investigating the processing time of three servlets. The average of all three processing times is built and an alarm is generated if the overall processing time is greater then a pre-defined value. How the developed monitoring component is integrated into the Geronimo architecture and how it is deployed and managed by the JConsole http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/ is content of this paper.

Overview about MBeans and GBeans

This section gives a short introduction of the management standard JMX (http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/) with its fundamental beans, the MBeans. It explains that Geronimo can be extended by new components, if they are GBeans.

Java Management Extension

Java Management eXtension (JMX) (http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/) standardizes the managing and monitoring of applications and services. It enables developers to write management programs for their applications in a vendor/neutral fashion. Another important standard in the area of J2EE is JSR-77 (http://jcp.org/en/jsr/detail?id=77). JSR-77 is a standard model for managing the J2EE platform and allows application server vendors to present performance metrics in a standard way. It defines a set of standard metric types that can be used to monitor J2EE platforms. The following types of metrics are defined in JSR-77: range statistics, boundary statistics, bounded range statistics, count statistics, and time statistics. Fundamental to JMX is the management bean, MBean. There are four types of MBeans (Standard, Dynamic, Model, Open), and each provide a different level of sophistication for management and monitoring (see http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/ for more details). In this paper, MBeans are used for the monitoring of servlets and for controlling the GBean monitor component.

Geronimo hosting our Monitor Component

Geronimo is in the first place a JavaTM 2 Platform Enterprise Edition (J2EE) application server, but can be seen as a general service container. The main focus of developing Geronimo was the managing and scaling of application servers. Geronimo's intention was never to re-implement a servlet or an EJB container, but to use existing open source applications (mainly from Apache http://www.apache.org/) whenever possible, plug it together and build a new application server.



The standard Geronimo distribution comes with Apache Tomcat http://tomcat.apache.org/ and EJB container (OpenEJB http://incubator.apache.org/openejb/) component. Extending Geronimo by a monitoring component, developed for this paper, is like Tomcat, or any other component as long as they are GBeans, as shown in the Figure: [#Geronimo extended by a monitor component]. The fundamental entity within Geronimo are Geronimo Beans (GBeans).

">Geronimo Beans

Everything in Geronimo is basically a Geronimo Bean (GBean). Geronimo's kernel handles these GBeans and stores them in it s repository. By default Geronimo uses not a database but a file directory named repository.



Users can install their own GBeans by describing them with a deployment plan and deploy them into Geronimo by using the GBeanBuilder (see Fig. [#Geronimo GBeans]). Every GBean must implement the GBeanLifecycle interface. This interface defines three methods: doStart(), doStop(), doFail() as you see in the class diagram (Fig. [#Class diagram of the management component example]). The GBeanLifecycle interface is the contract between the Geronimo plug-in framework and our application, the GBean. The Geronimo framework uses dependency injection (see Fowler: Inversion of control containers and the dependency injection pattern, Frod: Dependency injection in apache geronimo, part 1, Dependency injection in apache geronimo, part 2) to set GBean parameters during the deployment process. There are two ways to inject information during the deployment process of GBeans:

  1. getter/setter injection: framework injects information using the setter and getter methods of the GBean.
  2. constructor injection: framework injects information using the constructor of the GBean, when it is instantiated.

The example of this article is using constructor injection to pass the servlet MBean names and the MBean server reference to the monitor GBean.

The Server-Side Monitor Component

Subject of the section is a detailed architecture description of how the GBeans and MBeans are interacting. Discussed are the developed monitor classes and how to deploy the monitor component into Geronimo. Finally the monitor component is tested using the JConsole.

Geronimo Architecture Overview

First an overview about the integration of the monitor component into Geronimo's architecture is given in Figure \ref

Unknown macro: {GeronimoArchitectureExample}

. It shows the JMX-Layer with the MBeanServer and the MBeans, the Tomcat component and the monitor component.

Geronimo registers each GBean as a MBean with the MBean Server, when the server is started. Tomcat http://tomcat.apache.org/, for example, consists of several GBeans and therefore consists of several MBeans (TomcatWebContainer, TomcatWebConnector, TomcatEngine, TomcatJAASRealm, etc.).
For each servlet (S1, S2, S3) in Fig. [#Geronimo architecture with integrated monitor component] there exists a MBean (MBS1, MBS2, MBS3) with information defined in the JSR-77 specification. The dashed line objects are instantiated, when the sample monitor component (Servlet Monitor GBean) is deployed into Geronimo using the "GBean Builder". The MBeanServerKernelBridge registers each loaded GBean as a MBean (MBMC) at the MBean server. The instantiated thread (TC) retrieves information from the servlet MBeans (MBS1, MBS2, MBS3).

References

  • No labels