Wenn der GTM nicht verwendet wird, müssen sowohl die Objekte, als auch die Submaps und Symbole für ihre grafische Darstellung erzeugt werden. Dabei muß direkt mit dem User Interface API gearbeitet werden. Der GTM erspart also ein nicht unerhebliches Maß an Entwicklungsaufwand.
Der geringere Entwicklungsaufwand muß jedoch mit einer reduzierten Flexibilität bei der Topologiedarstellung erkauft werden. Wenn unterschiedliche Topologie-Views auf die gleichen CORBA-Ressourcen erstellt werden sollen (wie hier das Systemmanagement- und das Anwendungsmanagementmodell) müssen zwei getrennte Modelle in der GTM-Datenbank erzeugt werden (mit eigenem Protokollidentifikator), auch wenn die GTM-Objekte die gleichen realen Ressourcen repräsentieren.
Bei Verwendung des User Interface API können hingegen einem Objekt beliebig viele Symbole in unterschiedlichen Submap-Hierarchien zugeordnet werden. Konzeptionell ist die direkte Arbeit mit der Objekt-Datenbank und der grafischen Oberfläche also sinnvoller. Bei der Entwicklung des Prototypen wurde allerdings der GTM verwendet.
Der GTM hat ein API, mit dem Objekte in der zugehörigen Datenbank erzeugt werden können. Außerdem können Managementanwendungen über dieses API auf die Information in der Datenbank zugreifen.
CORBA-basierte Managementanwendungen bestehen in der Regel aus verteilten Objekten. Damit diese Objekte unabhängig von ihrer Lokation Einträge in der GTM-Datenbank erzeugen können und Zugriff auf die darin gespeicherte Information haben, wurde eine aus CORBA-Objektklassen bestehende ,,Kapselung`` für dieses API entwickelt.
Für jede Komponente des abstrakten GTM-Datenmodells wurde eine Objektklasse definiert. Über die Methoden der Klassen können die entsprechenden GTM-Objekte erzeugt und gelöscht werden. Normalerweise müssen beim Erzeugen eines GTM-Objekts viele ,,NetView-interne`` Parameter angegeben werden, wie z.B. der Protokollidentifikator oder der Typ des gewünschten Symbols. Bei den entwickelten Objektklassen wurden möglichst viele dieser Parameter bereits intern vordefiniert, um die NetView-spezifischen Details bei der Benutzung des APIs möglichst transparent zu machen.
Als Beispiel sei hier die IDL-Definition der Klasse Vertex gezeigt.
interface Vertex : SOMObject
{
void create_in_box(in string boxName,
in string vertexName,
in string label);
void create_in_graph(in string graphName,
in string vertexName,
in string label);
void delete_vertex(in string vertexName);
void change_vertex_status(in string vertexName,
in string vertexStatus);
}
Die Kapselung der Funktionsaufrufe zum Auslesen von Information aus der GTM-Datenbank wurde nicht mehr implementiert. Dazu müssen nämlich die teilweise komplexen Datenstrukturen der Rückgabeparameter dieser Funktionsaufrufe nach CORBA-IDL ,,gemappt`` werden. Dies ist zwar prinzipiell möglich, hätte jedoch einen zu großen Zeitaufwand erfordert.
In der GTM-Datenbank werden neben der CORBA-Topologie auch die Topologiemodelle anderer NetView-Anwendungen gespeichert, wie z.B. die der TMN-Plattform, des SAP-R/3-Managers und anderer. CORBA-Managementanwendungen können prinzipiell also auch auf diese Information zugreifen. Z.B. ist es denkbar, daß im Fehlerfall einer verteilten CORBA-Anwendung die Ursache nicht nur bei den CORBA-Komponenten selbst gesucht wird, sondern daß auch die in der GTM-DB gespeicherten Zustandsattribute von mit TMN überwachten Netzkomponenten berücksichtigt werden. Der vermeintliche Anwendungsfehler kann in Wirklichkeit nämlich auch darin begründet liegen, daß die Kommunikationsinfrastruktur nicht funktioniert.