Express (Distributed operating systems), v8.0 > Secure applications and their environment > Authenticate users > Select a registry or repository > Manage realms in a federated repository > Virtual member manager > Reference > Program model
Load the virtual member manager DataGraph model
Virtual member manager supports two ways to load the DataGraph model into memory: dynamic loading and static loading. Each method has advantages.
Dynamic loading
Dynamic loading means that the DataGraph model is loaded to memory as an ECore model at runtime from the XSD files through the XSDEcoreBuilder.
The advantages to this method are:
Extends easily
Unlike static loading, dynamic loading does not need to generate static model code. All schema definitions are defined and loaded from XSD file.
Allows changes to the virtual member manager built-in schema
New property types can be added to the virtual member manager built-in entity types through the wimxmlextension.xml file.
Supports adding new schema at run time
Exploiters can call the createSchema API at run time to create new entity types and property types. The disadvantages to this method are:
Loads slower
The time taken to load the XSD file is longer than loading static model code. The loading process occurs every time virtual member manager starts.
Cannot use native types
In this approach, the customers cannot cast the DataObjects to the native types (like PersonAccount, Group) and use the native methods on these types. For example, customers can only use setString(“givenname”, “Smith”) method of DataObject to set the given name, but cannot use setGivenname(“Smith”) of PersonAccount.
Has slower runtime performance
The performance of SDO using dynamic loading is slower than the static model.
Static loading
Static loading means that static model code is generated through EMF (Eclipse Modeling Framework) code generation at development time. The model code is an EMF implementation of SDO. The SDO application uses the package of the generated model code. This approach saves the time used for loading the model from XSD files in dynamic loading. It also allows the users to cast the DataObjects to native object types to improve runtime performance.
The advantages to this method are:
Loads faster
Compared with loading model from XSD files, loading mode from static model code is faster. This make the virtual member manager start time shorter.
Allows exploiters to use native types
DataObject can be cast to native types (like PersonAccount, Group) and use the native methods on these types. For example, DataObject can be cast to PersonAccount and the method “setGivenname” can be used to set the property “givenname”.
Has better runtime performance
By using native types and methods, the runtime performance of SDO is better than the dynamic loading method. The disadvantages to this method are:
Extends less easily
Extend schema needs generating static model code through Eclipse or RAD development environment. Virtual member manager exploiters need to have EMF, SDO and XML Schema knowledge to do extension.
Change to the virtual member manager built-in schema is more difficult
If the to add new property types to the virtual member manager built-in entity types (like PersonAccount and Group), we have to directly modify wimdomain.xsd and regenerate the virtual member manager static model code.
Does not support adding new schema at run time
Because the generated model code is fixed, you can not extend the virtual member manager schema at runtime.
Parent topic: Program model
Configure the virtual member manager model type
Extend virtual member manager functionality in the application