next up previous contents
Next: 4 JMAPI, CIM und Up: 3.3 Anlegen neuer JMAPI Previous: 3.3.1 Allgemeine Vorgehensweise

3.3.2 Aufbau der .mo-Datei

 Die Erläuterung des Aufbaus einer .mo-Datei erfolgt am einfachsten an einem Beispiel. Es sei eine neue Managed Object Klasse ExampleMO anzulegen, die die Wurzelklasse ManagedObjectImpl der MO Basisklassenhierarchie spezialisiert. Wie bereits oben erwähnt ist hierzu eine Datei ExampleMO.mo anzulegen. Diese Datei muß die Java-Klasse ExampleMOImpl definieren:

public class ExampleMOImpl 
    extends ManagedObjectImpl implements ExampleMO {
        // Attribute und Methoden
        // ...
}

Hierbei ist ExampleMO das Remote Interface, das später von JMAPI Clients benutzt wird, um mit den entsprechenden MO Instanzen auf dem MO Server zu kommunizieren. Die Klasse ExampleMO.class wird vom Managed Object Compiler Moco erzeugt. Moco erzeugt ebenfalls den Client-Stub und das Server-Skeleton ExampleMOImpl_Stub.class und ExampleMOImpl_Skel.class, die für die RMI Kommunikation zwischen Client und MO Server benötigt werden. ExampleMOImpl erbt von ManagedObjectImpl die Methoden für die Interaktion mit der Datenbank. Tabelle 3.1 führt die von Moco erzeugten Dateien tabellarisch auf.


 
Tabelle 3.1: Von Moco erzeugte Dateien
Datei Bedeutung
ExampleMO.class RMI Interface für das MO
ExampleMOImpl.class Implementation des Interface
ExampleMOImpl_Stub.class RMI Client Stub
ExampleMOImpl_Skel.class RMI Server Skeleton
DBExampleMO.class Dient der persistenten Speicherung in der Datenbank
DBExampleMO.import Hilfsdatei zum Erzeugen des Datenbankschemas
 

Der Body der Funktionsdefinition von ExampleMOImpl enthält nun zunächst eine Auflistung aller Attribute der neuen Managed Object Klasse mit zugehörigem Datentyp. In der Regel werden alle Attribute in der Datenbank gespeichert. Ist dies für einige Attribute nicht erwünscht, etwa weil sich diese sehr oft ändern, so können diese, wie bereits erwähnt, durch Verwendung des Schlüsselwortes transient speziell gekennzeichnet werden.

Als Beispiel seien zwei Attribute anzulegen, eines vom Typ String, das andere vom Typ Integer, wobei jedoch nur das erste in der Datenbank zu speichern sei:

    String            attr1;
    transient int     attr2;

Als nächstes sind für alle Attribute get- und set-Methoden zu definieren. Operationen auf Managed Objects erfolgen immer innerhalb einer Session, welche einen Transaktions- und Security-Kontext verwaltet.

Für das erste Attribut in obigem Beispiel würden die get- und set-Methoden wie folgt aussehen:

    public String getAttr1(Session session) 
      throws AuthorizationException, RemoteException {
        return (String)getPropertyByName(session, "attr1");
    }

    public void setAttr1(Session session, String _attr1) 
      throws NotInUpdateException, AuthorizationException, 
             RemoteException
    {
          setPropertyByName(session, "attr1", _attr1);
    }

Die Methoden getPropertyByName und setPropertyByName sind vordefinierte Methoden des Interfaces ManagedObject, die den entsprechenden Wert aus der Datenbank lesen bzw. in die Datenbank schreiben.

Für das als transient definierte Attribut, das nicht in der Datenbank gespeichert wird, kann eine andere Implementierung der get- und set-Methoden gewählt werden.

Nach der Definition der Attribute und ihrer zugehörigen get- und set-Methoden können nun beliebige weitere Methoden hinzugefügt werden. Auch die drei speziellen Methoden (vgl. Abschnitt 6.6)

public synchronized void performAddActions(Session session) {};
public synchronized void performModifyActions(Session session) {};
public synchronized void performDeleteActions(Session session) {};
können umdefiniert werden.


next up previous contents
Next: 4 JMAPI, CIM und Up: 3.3 Anlegen neuer JMAPI Previous: 3.3.1 Allgemeine Vorgehensweise
Copyright Munich Network Management Team