Benutzeroberfläche für einen CORBA-Agenten

 Als Beispiel für die Verwendung der AVM-KLassen soll im folgenden die Erstellung einer Benutzeroberfläche für einen CORBA-Agenten dienen. Neben der Verwendung der AVM-Klassen führt es auch eine Möglichkeit zur Integration anderer Managementarchitekturen in das JMAPI-Framework vor.

Im Rahmen von [Mül98] wurde die prototypische Implementierung eines CORBA-Agenten vorgenommen, der u.a. zur Benutzerverwaltung auf den UNIX-Workstations des Lehrstuhls eingesetzt werden kann. Der Agent liest die vorhandene Benutzerinformation aus der lokalen Passwort-Datei und aus den NIS-Maps aus und erzeugt daraufhin für jeden Benutzer ein Account-Objekt. Die Menge aller Account-Objekte wird von einem AccountFactory-Objekt verwaltet.

Am Beispiel der Account-Objects soll im folgenden demonstriert werden, wie die Erstellung einer JMAPI-konformen Oberfläche mit Hilfe der AVM-Klassen realisiert werden kann.

Es wäre zunächst denkbar, eine Managed-Object-Klasse AccountMO anzulegen und dann für jeden Benutzer ein entsprechendes AccountMO-Objekt auf dem Managed Object Server zu verwalten. Mit Hilfe der AVM Integration Classes (vgl. Abschnitt 7.3) ließe sich dann eine Benutzeroberfläche konstruieren, die auf die AccountMO-Klassen zugreift.Änderungen an AccountMO-Objekten müßten auf entsprechende Änderungen an den zugehörigen CORBA Account-Objekten abgebildet werden.

Diese Vorgehensweise hätte allerdings folgende Nachteile:

• Für jeden Benutzer würden sowohl ein JMAPI-AccountMO-Objekt auf dem Managed Object Server als auch ein CORBA-Account-Object angelegt werden. Diese doppelte Repräsentation würde nur für die einfachere Erstellung der Benutzeroberfläche eingeführt werden, wäre aber ansonsten unnötig.
• Da die Kommunikation der Managed Objects mit der CORBA- AccountFactory mittels IIOP erfolgt, kann nach Abschnitt 6.6 der in JMAPI integrierte Transaktionsmechanismus nicht genutzt werden. Wie in Abschnitt 8.4 gezeigt wird, kann es daher u.U. sogar zu Inkonsistenzen zwischen dem Zustand des AccountMO und des CORBA-Account-Objekts kommen.
• Mit dem doppelten Verwaltungsaufwand ist auch ein Performance-Verlust verbunden.

Aus diesen Gründen wurde eine andere Vorgehensweise gewählt, bei der das JMAPI-Client-Applet direkt auf das CORBA-AccountFactory-Objekt zugreift (siehe Abbildung 7.3).

  

Abbildung 7.3: Kommunikation des JMAPI-Applets mit dem CORBA-Agenten

Zur Darstellung der Account-Daten wurde die Klasse sunw.admin.avm.base.SimpleContentManager gewählt. Sie ermöglicht die Darstellung von Daten wahlweise in Tabellenform, oder als eine Reihe von Icons. Abbildung 7.4 zeigt die zugehörigen Darstellungen der Account-MOs.

Neben der Darstellungsform als Icons oder als Tabelle lassen sich auch noch eine Reihe von Filter- und Sortiereigenschaften festlegen. Hierzu dient das View-Pulldown-Menü am oberen Rand des Applets, über welches vier Dialog-Fenster anwählbar sind.

• Der ,,Properties...`` Dialog erlaubt zwischen der Icon- und der Tabellendarstellung zu wählen.
• Mittels des ,,Filter...`` Dialogs kann eine Teilmenge von Account-Objecten ausgewählt werden, deren Attributwerte gewisse Bedingungen erfüllen, beispielsweise ,,Alle Benutzer, deren Kennung mit dem Buchstaben S beginnt``. Dies ist etwa vergleichbar mit einer Selektionsoperation bei einer relationalen Datenbankabfrage.
• Der ,,Sort...`` Dialog ermöglicht ein Sortieren der dargestellten Account-Objekte. Es kann nach einem oder mehreren Attributen sortiert werden. Ferner ist es möglich, in auf- oder absteigender Reihenfolge zu sortieren.
• Mittels des ,,Display...`` Dialogs kann schließlich aus der Menge aller Attribute eine Teilmenge ausgewählt werden. Nur die ausgewählten Attribute werden dann in der Tabellenform angezeigt. Dies entspricht einer Projektionsoperation bei einer Anfrage an eine relationale Datenbank.

Die Realisierung der obengenannten Filter-, Sort- und Display-Funktionen erfolgt über sogenannte Pipes: Die Klasse sunw.admin.avm.base.TableDataContentManager, von der die Klasse SimpleContentManager erbt, verwaltet je ein TableFilterPipe-, TableSortPipe- und ein TableViewPropertiesPipe-Objekt, welche die obigen Funktionen umsetzen.

Der zugehörige Programmcode findet sich in Anhang B.

  

Abbildung 7.4: Tabellen- und Icondarstellung der Benutzer-Accounts