6 Java Management Extensions

  Mitte Juni 1999 wurde die Draft Version der neuen Java Management Extensions (JMX) Spezifikation [23] veröffentlicht und für einen öffentlichen Review Prozeß freigegeben. JMX integriert die früheren Entwicklungen im Bereich der Java Management-API (JMAPI) und von JDMK in ein Java basiertes Management Framework. Im Gegensatz zu JDMK liegt der Fokus von JMX nicht nur auf dem Agenten, sondern es soll auch die Manager-Seite betrachtet werden. In der vorliegenden Spezifikation ist der Manager jedoch noch nicht spezifiziert.

Da JDMK als integraler Bestandteil von JMX betrachtet werden kann, soll hier ein kurzer Überblick über die neuen Entwicklungen gegeben werden. Daneben wird die Frage untersucht, inwieweit die, im vorigen Abschnitt betrachteten, für JDMK kritischen Punkte auch für JMX gelten. Dabei muß natürlich beachtet werden, daß die JMX-Spezifikation bisher noch keinen endgültigen Status erreicht hat. Informationen über den aktuellen Stand der Spezifikation sind auf der Web-Seite von Sun Microsystems zu finden.

Die Architektur von JMX ist der in Abb. 1 dargestellten Architektur von JDMK sehr ähnlich. JMX unterscheidet zwischen Manager-, Agenten- und Instrumentierungsebene: Die für die Verwaltung einer Ressource verantwortlichen M-Beans innerhalb eines Agenten bilden die Instrumentierungsebene. Eine zu verwaltende Ressource kann in JMX eine Anwendung, ein Dienst oder eine (Hardware-) Komponente sein. Die Instrumentierungsebene wird der Managementanwendung, die die Managerebene darstellt, durch die Agentenebene zugänglich gemacht. Die Agentenebene stellt eine Kommunikationsschnittstelle, eine Menge von Standarddiensten und die Laufzeitumgebung für M-Beans bereit. Das Core Management Framework von JDMK wurde in MBean Server umbenannt.

Eine der größeren Änderungen in JMX betrifft die MBeans, die in vier verschiedene Klassen eingeteilt wurden: Das Standard MBean repräsentiert eine Teilmenge der aus JDMK bekannten M-Beans. An der Schnittstelle dieses Beans werden Methodenaufrufe zugänglich gemacht. Im Gegensatz dazu werden bei dynamischen MBeans Attribute und Signaturen von Operationen durch fest definierte Zugriffsfunktionen bekanntgegeben. Damit wird es einfach, bestehende (Legacy) Anwendungen durch JMX-Agenten zu kapseln. Ein offenes MBean ist eine Unterart des dynamischen MBeans, das nur bestimmte, fest vordefinierte Datentypen und Funktionen zur Verfügung stellt. Zusätzlich wird mit dem Interface MBeanInfo detailierte Meta-Information zum entsprechenden MBean geliefert. Das Ziel hierbei ist es, sich ,,selbst beschreibende`` MBeans zu erhalten, die sehr einfach benutzt werden können. Das Modell MBean -- ein weiteres dynamisches MBean -- stellt ein generisches und konfigurierbares Management Template für Managementobjekte dar. Es kann entweder von einem JMX-Agenten, von anderen MBeans oder sogar von der zu verwaltenden Ressource selbst instantiiert werden. Zum Zeitpunkt der Erzeugung können die Signaturen der Operationen und die Menge der zur Verfügung gestellten Attribute durch XML, OMG IDL oder Java beschrieben werden. Außerdem bietet das Modell MBean die Möglichkeit der persistenten Speicherung.

Das Konzept des Adapters in JDMK wird nun in Protokoll Adapter und Konnektoren aufgeteilt. Protokoll Adapter werden verwendet, um JMX-Agenten mit Anwendungen, die nicht der JMX-Spezifikation entsprechen (z.B. SNMP, Common Information Model (CIM) [3] oder andere) zu verbinden. Im Gegensatz dazu werden Konnektoren eingesetzt, um eine entfernte JMX-Management Anwendung mit einem JMX-Agenten zu verbinden.

JMX erweitert auch den Event Mechanismus von JDMK zu einem Notification Model. Damit muß sich ein Event-Listener nur einmal registrieren, um alle Events eines Agenten zu empfangen. Mit einem Notification Filter können dann bestimmte Typen von Events selektiert werden. Wenn sich der Wert eines bestimmten MBean Attributs ändert oder wenn ein MBean erzeugt oder gelöscht wird, können Events erzeugt werden.

Die Dienste, die im Abschnitt 3.2 beschrieben wurden, sind auch in JMX enthalten. Die vordefinierten Management Dienste Timer sowie Counter und Gauge Monitor wurden entsprechend dem Notification Model erweitert.

Um JMX in bestehende Management Lösungen integrieren zu können, wurde eine zusätzliche Management Protokoll-API definiert, welche eine offene Schnittstelle spezifiziert, die auch von anderen Herstellern, für eigene Entwicklungen genutzt werden kann. Gegenwärtig sind eine SNMP-API [24] und eine CIM/WBEM-API [22] definiert.

Die endgültige JMX-Spezifikation wird sowohl eine Referenzimplementierung als auch einen Kompatibilitätstest festlegen. Die Referenzimplementierung soll es Entwicklern erleichtern, JMX konforme Anwendungen zu entwickeln, wohingegen der Test die Kompatibilität mit der Spezifikation überprüfen soll. Allerdings ist noch keines der beiden spezifiziert oder gar als Implementierung erhältlich.

Basierend auf der gegenwärtigen Spezifikation muß festgestellt werden, daß die in Abschnitt 5 identifizierten Schwächen auch in JMX noch nicht behoben wurden. Bis zu welchem Grad der Review Prozeß diese Schwächen eliminieren wird bleibt eine offene Frage. Dies betrifft insbesondere die Managerebene, die im Moment noch völlig unspezifiziert ist.