Virtual Member Manager unterstützt zwei Arten, das Datengraphmodell in den Speicher zu laden: dynamisches Laden und statisches Laden. Jede Methode hat ihre Vorteile.
Dynamisches Laden
Dynamisches Laden bedeutet, dass das Datengraphmodell während der Ausführungszeit aus den XSD-Dateien über "XSDEcoreBuilder" in den Speicher als ECore-Modell geladen wird.
Vorteile dieser Methode:
- Geringer Aufwand bei der Erweiterung
- Im Gegensatz zu statischem Laden muss beim dynamischen Laden kein Code für ein statisches Modell generiert werden. Sämtliche Schemadefinition werden über eine XSD-Datei definiert und geladen.
- Zulässigkeit von Änderungen am integrierten Virtual Member Manager-Schema
- Neue Merkmaltypen können den bereits integrierten Virtual Member Manager-Entitätstypen über die Datei
"wimxmlextension.xml" hinzugefügt werden.
- Unterstützung für das Hinzufügen neuer Schemata während der Ausführung
- Benutzer können die API
"createSchema" während der Ausführung aufrufen, um neue Entitätstypen und Merkmaltypen zu erstellen.
Nachteile dieser Methode:
- Langsamerer Ladevorgang
- Man benötigt zum Laden der XSD-Datei mehr Zeit als zum Laden des Codes für ein statisches Modell. Der Ladeprozess erfolgt mit jedem Start von Virtual Member Manager.
- Keine Möglichkeit zur Verwendung von nativen Typen
- Gemäß diesem Ansatz kann der Kunde die Datenobjekte nicht in native Typen umsetzen (wie "PersonAccount" oder "Group") und für diese Typen native Methoden verwenden. So kann der Kunde z. B. von "DataObject" nur die Methode "setString(“givenname”, “Smith”)" verwenden, um den Vornamen festzulegen, nicht jedoch die Methode "setGivenname(“Smith”)" von "PersonAccount".
- Schlechtere Laufzeitleistung
- Wenn SDO (Service Data Objects) dynamisches Laden verwendet, ist die Leistung schlechter als beim statischen Modell.
Statisches Laden
Statisches Laden bedeutet, dass der Code für ein statisches Modell während der Entwicklungszeit über die EMF-Codegenerierung (Eclipse Modeling Framework) erfolgt. Der Modellcode ist eine EMF-Implementierung von SDO. Die SDO-Anwendung verwendet das Paket des generierten Modellcodes. Dieser Ansatz spart die Zeit, die für das dynamische Laden des Modells aus XSD-Dateien benötigt wird. Der Benutzer kann außerdem die Datenobjekte in native Objekttypen umsetzen, um die Laufzeitleistung zu verbessern.
Vorteile dieser Methode:
- Schnellerer Ladevorgang
- Im Vergleich zum Laden des Modells aus XSD-Dateien ist das Laden des Codes für das statische Modell deutlich schneller. Dies verkürzt wiederum die Startzeit von Virtual Member Manager.
- Zulässige Verwendung von nativen Typen durch Nutzer
- Datenobjekte können in native Typen umgesetzt werden (wie "PersonAccount" oder "Group") und native Methoden für diese Typen verwenden. Beispiel: Ein Datenobjekt kann in "PersonAccount" umgesetzt werden und mit der Methode “setGivenname” kann das Merkmal “givenname” festgelegt werden.
- Bessere Laufzeitleistung
- Durch das Verwenden nativer Typen und Methoden ist die Laufzeitleistung von SDO besser als die Methode des dynamischen Ladens.
Nachteile dieser Methode:
- Größerer Aufwand bei einer Erweiterung
- Die Schemaerweiterung
erfordert die Generierung von Code für das statische Modell über Eclipse oder eine RAD-Entwicklungsumgebung.
Um eine Erweiterung auszuführen, benötigt der Benutzer von Virtual Member Manager Kenntnisse im Zusammenhang mit EMF-, SDO- und XML-Schemata.
- Größere Schwierigkeit bei Änderung des integrierten Virtual Member Manager-Schemas
- Wenn Sie zu den integrierten Entitätstypen (wie "PersonAccount" oder "Group") von Virtual Member Manager neue Merkmaltypen hinzufügen möchten, müssen Sie die Datei "wimdomain.xsd" direkt ändern und den Code des statischen Virtual Member Manager-Modells neu generieren.
- Keine Unterstützung für das Hinzufügen neuer Schemata während der Ausführung
- Da der generierte Modellcode festgelegt ist, können Sie das Virtual Member Manager-Schema nicht während der Ausführung erweitern.