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 Person, 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
Person.
- 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 Person, Group) and use the
native methods on these types. For example, DataObject can be cast to Person
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 Person 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.