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
- Extending 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.
- Changing to the virtual member manager built-in schema is more
difficult
- If the you want to add new property types to the virtual member
manager built-in entity types (like PersonAccount and Group), you
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.