JMX - Management ohne Wasserkopf

Autor:
Kristian Köhler
Orientation in Objects GmbH
Kristian Köhler
Kristian Köhler
Datum:Februar 2003

Java hat sich auf der Serverseite durchgesetzt. Eine produktive Serveranwendung muß zur Laufzeit überwacht und verwaltet werden. Bisher gab es keine einheitliche Schnittstelle für das Management von Java Anwendungen. Mit der JMX Spezifikation verspricht SUN diese Lücke zu schließen.

Der vorliegende Artikel beschreibt anhand eines Beispiels die Java Management eXtensions (JMX), die mittlerweile in der Version 1.2 verfügbar sind.

Wer hat's erfunden?

Die JMX Spezifikation ist im Rahmen des Java Community Process (JSR 3) unter Beteiligung großer Firmen wie z. B. IBM, BEA Systems und Borland entstanden. Auch die Apache Software Foundation ist Teil der Expert Group, die die JMX Spezifikation entwickelt.

Viele Serveranwendungen setzen mittlerweile auf die JMX Spezifikation. So bringen z. B. JBoss, Tomcat aber auch BEAs Weblogic oder IBMs Webshere bereits von Haus aus JMX Schnittstellen mit. Im Rahmen des Java Specification Request (JSR) 176, der sich mit der Version 1.5 des Java Development Kits beschäftigt, wird erwogen, die JMX Spezifikation zum Standardumfang des Java JDKs zu machen.

Was ist JMX?

JMX stellt einen standardisierten Weg zur Verfügung Java Anwedungen und Dienste verwaltbar zu machen. Im Gegensatz zu vielen anderen Ansätzen handelt es sich hierbei nicht um eine properitäre Lösung eines bestimmten Herstellers, sondern um eine, durch den Java Community Process entwickelte, Spezifikation. Sie beschreibt eine Archtitektur, Design Patterns, eine API, Verwaltungsdienste für Anwendungen und Netzwerke sowie Monitoring Dienste für Java.

Über die einheitliche JMX Schnittstelle läßt sich jede konforme Anwendung prinzipiell von jeder JMX fähigen Management Konsole ansprechen. Im Rahmen des JSR 77 wird außerdem an einer Management Schnittstelle gearbeitet, mit der mehrere Applikationen gruppiert und über eine zentrale Konsole verwaltet werden können.

Manageable ohne große Investition

Kern der JMX Architektur ist ein Objekt Repository, in dem sämtliche zu verwaltenden Objekte angemeldet werden. Der sogenannte 'management agent' besitzt nun die Aufgabe dieses Repository zu verwalten und eine umfangreiche Management Infrastruktur zur Verfügung zu stellen.

Um die eigene Java Anwendung manageable zu machen, kann ein Objekt Server in diese integriert und bestimmte Funktionalität in Form von Manageable Beans registriert werden.

Die Anforderungen an das Anwendungsdesign sind minimal. So lassen sich auch bestehende Anwendungen leicht um eine Management Schnittstelle ergänzen.

Skalierbare Management Architektur

Bei jedem JMX Service handelt es sich um eine unabhängige Einheit, die, abhängig von den Anforderungen, in den Management Agent eingebunden werden kann oder nicht. So lassen sich Minimalarchitekturen aber auch riesige "Serverfarm Architektruren" realisieren. Jeder Service kann im JMX Umfeld dynamisch zur Laufzeit an- und auch wieder abgemeldet werden.

Integration bestehender Systeme

JMX konforme Management Agents lassen sich über verschiedene Protokolle ansprechen. Die von SUN ausgelieferte Referenz Implementierung liefert so z. B. ein HTML Frontend mit. Aber auch Protokolle wie SNMP, WBEM und TMN können mit JMX benutzt werden.

Architektur

Die JMX Architektur teilt sich, wie Abbildung 1 zeigt in drei Bestandteile:

Diese sollen im Folgenden kurz beschrieben werden:

JMX Architektur
Abbildung 1.) JMX Architektur

Instrumentation Level

Auf Ebene des Intrumentation Levels befinden sich die zu überwachenden Resourcen. Eine Resource kann z. B. eine Anwendung, ein Dienst oder ein User darstellen. Diese Resourcen werden durch ein oder mehrere MBeans repräsentiert. Zum Austausch von Informationen zwischen den MBeans ist ein Benachrichtigungsmechanismus, ähnlich dem Event / Listener Mechanisumus der JavaBeans, spezifiziert.

Agent Level

Innerhalb des Agent Level sind Agenten definiert, die die zu verwaltenden Resourcen direkt ansprechen und sie entfernten Management Anwendungen zur Verfügung stellen. Ein Client erhält nur über diese Agents Zugriff auf die Resourcen. Das Agent Level besteht zwingend aus folgenden Bestandteilen:

MBean Server Implementierung

Agent Services

Für den externen Zugriff auf den Server muss zusätzlich ein Kommunikationsadapter- oder Connector vorhanden sein. Diese sind im Gegensatz zur Server Implementierung und den Services noch nicht spezifiziert (Stand Januar 2003).

Distributed Services Level

Das Distributed Services Level ist in der aktuellen Version 1.2 der Spezifikation nicht näher beschrieben. (The detailed definition of the distributed services level is beyond the scope of this phase of the specification.)

Das Distributed Services Level soll die Schnittstelle bilden mit der Management Applikationen auf Agents innerhalb des Servers zugreifen können. Dieser Zugriff kann über verschiedene Protokolle erfolgen. Die Spezifikation spricht hier z. B. von HTML und SNMP. Teil der Referenzimplementierung ist ein HTML Adapter, der den externen Zugriff auf den JMX Server ermöglicht (siehe Beispielanwendung).

MBean

MBeans sind die eigentlichen überwachbaren Ressourcen. Für jedes MBean muss eine Management Schnittstelle definiert werden, die dem MBean Server folgende Informationen zur Verfügung stellt:

Grundsätzlich werden vier verschiedene Arten von MBeans unterschieden, die im Folgenden näher beschrieben werden:

Die vier Typen unterscheiden sich nur in der Definition ihrer Management Schnittstelle. Standard MBeans z. B. definieren ihre Schnittstelle über ein statisches Java Interface, alle anderen MBean Typen verwenden MetaData Objekte für die Definition ihrer Schnittstelle.

Typen von MBeans

Standard MBean

Standard MBeans stellen die einfachste Möglichkeit dar, Java Objekte in der JMX Welt zur Verfügung zu stellen. Hauptbedingung für Standard MBeans ist das vorhandensein eines statischen Management Interface, das die Management Attribute und Operationen enthält. Das eigentliche MBean muß dieses Interface implementieren und die Management Methoden zur Verfügung stellen.

Möchte man z. B. das Objekt Kaffeemaschine über JMX verwalten, so muß man das Interface KaffeemaschineMBean definieren, das sämtliche Management Attribute und Operationen enthält. Das Interface könnte z. B. wie in Abbildung 2 dargestellt aussehen.

MBean
Abbildung 2.) Standard MBean Kaffeemaschine

Attribute werden, wie bei Java Beans, über Getter und Setter zur Verfügung gestellt. Operationen werden über "normale" Methodendefinitionen angegeben. Der Suffix MBean ist in diesem Zusammenhang wichtig, da der MBean Server über Introspection alle implementierten Interfaces des MBeans ermittelt und die Klasse als Standard MBean behandelt, wenn ein Interface mit dem Klassennamen und Suffix MBean gefunden wird.

Dynamic MBean

Wie der Name schon andeutet bieten Dynamic MBeans im Vergleich zu Standard MBeans eine dynamischere Management Schnittstelle. Sie implementieren im Gegensatz zu den Standard MBeans das generische javax.management.DynamicMBean Interface, das dem MBean Server Methoden zur Verfügung stellt, die Management Schnittstelle zu ermitteln (siehe Abbildung 3 ). So kann z. B. das Interface zur Laufzeit verändert werden. Die Schnittstelle wird über MBean MetaData Klassen, die beim Methodenaufruf von getMBeanInfo() zurückgegeben werden, definiert.

DynamicMBean
Abbildung 3.) Dynamic MBean

Open MBean

Open MBeans wurden als letzter MBean Typ zur Spezifikation hinzugefügt. Sie waren in der Version 1.0 noch nicht vollständig spezifiziert; ab Version 1.1 sind sie optional und in Version 1.2 sind sie nun zwingend vorgeschrieben.

Das Ziel der Open MBeans ist es Management Applikationen und deren Benutzern ein Mechanismus zur Verfügung zu stellen, mit dem es möglich wird, neue Objekte zur Laufzeit zu verstehen und zu verwenden.

Im Gegensatz zu den Standard MBeans oder den Dynamic MBeans gibt es kein "Open MBean Interface", daß implementiert werden muss. Ein Open MBean implementiert das javax.management.DynamicMBean Interface und erlangt seine Offenheit durch reichhaltige Metadaten, die es veröffentlicht, sowie durch wohldefinierte Datentypen in seinem Management Interface. Konstruktoren, Attribute, Methodenparameter und Rückgabewerte müssen aus sogenannten "Basic Data Types" bestehen. Dies hat den Vorteil, daß neue MBeans auch ohne Neuübersetzen sofort in einem MBean Server verwendet werden können und Administrationstools keine anwendungsspezifischen Klassen zur Verfügung haben müssen.

Folgende Liste zeigt die "Basic Data Types", die in der Schnittstelle vorhanden sein dürfen:

Model MBean

Model MBeans sind eine weitere Erweiterung zu den Dynamic MBeans. Sie sind generische, konfigurierbare MBeans, die dazu benutzt werden können schnell so gut wie jede Ressource managebar zu machen.

Zusätzlich implementieren Model MBeans das javax.management.PersistentMBean Interface (siehe Abbildung 4 ), was MBeans mit zusätzlichen Methoden zum Speichern von Zuständen erweitert.

ModelMBean
Abbildung 4.) Model MBean

Da sich die verschiedenen JMX Implementierungen in Punkten wie z. B. dem transaktionalen Verhalten, Caching und Skalierbarkeit unterscheiden können, wird hier von der Spezifikation nicht genau angegeben, wie der Persistenzmechanismus implementiert sein muss. Einziger vorgeschriebener Punkt ist, daß jede Implementierung ein javax.management.modelmbean.RequiredModelMBean zur Verfügung stellt. Da sich in diesem Punkt die Implementierungen sehr stark unterscheiden, wird oft empfohlen, eine eigene ModelMBean Implementierung zu erstellen, damit man beim Wechsel der Implementierung gleiches Verhalten erwarten kann.

Beispiel eines MBeans

Im Folgenden soll ein einfaches Standard MBean implementiert werden, daß in einem JMX konformen Server deployed werden kann. Es handelt sich hierbei um ein Schulungs Bean, daß der Einfachkeit halber nur ein Attribut name und eine Opertion print über die Management Schnittstelle zur Verfügung stellt.

Auf das Attribut name soll lesend sowie schreibend zugegriffen werden können. Die Operation print soll den Namen der Schulung auf der Kommandozeile ausgeben.

Implementiert werden muss, wie in Abbildung 5 ersichtlich, ein Interface de.oio.jmx.SchulungMBean sowie die Klasse de.oio.jmx.Schulung.

MBean Beispiel
Abbildung 5.) Schulung MBean

Mit dem Interface de.oio.jmx.SchulungMBean (Listing 1) wird die Management Schnittstelle definiert. Lese- und Schreibfunktionalität wird über die Get- und Set- Methode im Interface definiert. Die Management Operation wird als "normale" Methodendefinition angegeben.

 1 package de.oio.jmx;
 2
 3 public interface SchulungMBean {
 4
 5   //Management Attribute
 6   public String getName();
 7   public void setName(String name);
 8
 9   //Management Operation(en)
10   public void print();
11
12 }

Listing 1.) SchulungMBean.java

Das eigentliche Bean (Listing 2) muß nun dieses Interface implementieren. Damit es sich um eine JMX konforme Implementierung handelt, muss es sich um eine öffentliche, nicht abstrakte Klasse handeln, die einen öffentlich zugänglichen Konstruktor besitzt.

 1 package de.oio.jmx;
 2
 3 public class Schulung implements SchulungMBean {
 4
 5   private String name = null;
 6
 7   /**
 8   * Constructor for Schulung.
 9   */
10   public Schulung() {
11	 super();
12   }
13
14   /**
15   * @see de.oio.jmx.SchulungMBean#getName()
16   */
17   public String getName() {
18	 return name;
19   }
20
21   /**
22   * @see de.oio.jmx.SchulungMBean#setName(java.lang.String)
23   */
24   public void setName(String name) {
25	 this.name = name;
26   }
27
28   /**
29   * @see de.oio.jmx.SchulungMBean#print()
30   */
31   public void print() {
32	 System.out.println("Schulung: " + name);
33   }
34
35 }

Listing 2.) Schulung.java

Damit das MBean verwendet werden kann, muß es in einem MBean Server "deployed" werden. Im dargestellten Code wird aus diesem Grund (Listing 3 - Zeile 17) über die MBeanServerFactory ein neuer MBeanServer erstellt und in Zeile 22 das Objekt am Server angemeldet. Jedes MBean, das am Server angemeldet wird, muss über einen eindeutigen Namen verfügen. In der JMX Welt werden hierzu ObjectName Objekte verwendet, mit denen man eine hirarische Namensstruktur abbilden kann.

Für die Veröffentlichung soll die Referenzimplementierung des HTML Adapters von SUN verwendet werden. Der Adapter ist selbst als MBean implementiert und kann auch wieder am Server angemeldet werden.

Nach Start der Anwendung kann man sich mittels eines Internetbrowser mit dem HTML Adapter verbinden und unser Sschulungs MBean managen (siehe HTML Adapter ).

 0 package de.oio.jmx;
 1
 2 import javax.management.InstanceAlreadyExistsException;
 3 import javax.management.MBeanRegistrationException;
 4 import javax.management.MBeanServer;
 5 import javax.management.MBeanServerFactory;
 6 import javax.management.MalformedObjectNameException;
 7 import javax.management.NotCompliantMBeanException;
 8 import javax.management.ObjectName;
 9
10 import com.sun.jdmk.comm.HtmlAdaptorServer;
11
12 public final class Agent {
13
14   public static void main(String[] args) {
15
16	 try {
17	   MBeanServer server = MBeanServerFactory.createMBeanServer();
18
19	   ObjectName name = new ObjectName("beispiel:name=Schlung");
20
21	   server.registerMBean(new Schulung(), name);
22
23	   HtmlAdaptorServer adaptor = new HtmlAdaptorServer();
24	   ObjectName adaptorName =
		   new ObjectName("adaptor:proptocol=HTTP");
25	   server.registerMBean(adaptor, adaptorName);
26	   adaptor.start();
27
28	 } catch (MalformedObjectNameException e) {
29	   e.printStackTrace();
30	 } catch (InstanceAlreadyExistsException e) {
31	   e.printStackTrace();
32	 } catch (MBeanRegistrationException e) {
33	   e.printStackTrace();
34	 } catch (NotCompliantMBeanException e) {
35	   e.printStackTrace();
36	 }
37
38   }
39
40 }

Listing 3.) Agent.java

HTML JMX Adapter
Abbildung 6.) HTML Adapter

Fazit

Mit der JMX Spezifikation wird es möglich schlanke, nicht properitäre Managementschnittstellen zu implementieren und mit der eigenen Anwendung auszuliefern. Bei einer Neuimplementierung sollte auf jeden Fall JMX als Managementschnittstelle verwendet werden. Aber auch bestehende Anwendungen lassen sich mit geringem Aufwand auf JMX umstellen. Durch den Einsatz von JMX erhält die Anwendung gleichzeitig die Möglichkeit über viele freie, wie auch kommerzielle Administrationstools verwaltet zu werden. Der Aufwand einer Eigenimplementierung entfällt also!

Kristian Köhler, Januar 2003

Referenzen

Java Management Extensions
(http://java.sun.com/products/JavaManagement/)

Zum Geschaeftsbreich Competence Center