Abstract 

This article discusses our current Teiid Designer extension model framework (capabilities and limitations) and the design of a more extensible framework to replace it.

Background

Teiid Designer currently provides an "Extension Model" framework which allows users to create metamodels that extend other metamodels in order to add custom properties to specified entities. These properties may be defined as optional or required and may have a default value.

An Extension model is an EMF-based construct utilizing the feature-oriented properties of all other Teiid Designer metamodels. The metadata describing the default values and attribute's behavior (changeable, derived, required, ordered, unsettable, upper/lower bounds, etc...) are all stored in the Extension model. The only properties stored in your extended model are the non-default values.

NOTE:  Each metamodel can be extended by 0 or 1 extension model.

When an extended relational model is "Indexed" during VDB validation, ALL extension properties are added to the Teiid metadata records. These include both the properties discovered in the extended relational model as well as the default values defined in the Extension model.

A simple example would be to create a "RelationalColorExtensions.xmi" extension model to add a "color" property to relational table.

A relational model, for instance, that is extended by RelationalColorExtensions.xmi will contain an annotations object for each extended object type as shown below:

If a default value is defined for the property and is not overridden, then the key/value will NOT be stored as a <tags ........ /> entry but still include an empty annotations element.

Limitations

1. The current framework allows for only 1 extension model.
2. Extension models are included as a dependent models in VDBs.
3. When sequenced through publishing into the Modeshape repository none of the default "extended" property values are currently sequenced. There is no mechanism in Modeshape to associate 2 or more documents in this way.
4. When using the EMF Extension Model, EMF controls when Annotation objects are created, and we're creating annotation objects even when none are strictly needed (e.g., all the tags in the annotation have default values, and thus don't appear in the XMI file). The result is a lot of unnecessary Annotation objects.

New Requirements

1. Allow using multiple extension models per metadata model.
2. Provide mechanism to include default (or initial) values for extended properties in extended model.
3. Remove need for separate EMF Extension Model.

Design Proposal

1. Define a new Eclipse/Teiid Designer extension point to allow contributions for multiple "Model Extensions"
   • This extension would utilize namespaced IDs and property keys
   • Define the extended properties using JCR node type definitions and property definitions. Property definitions are as capable as the older metamodel extensions to represent features in a metaclass: they have types, default values, constraints, etc. and are defined within namespaces; these node and property definitions would replace the EMF Extension Model
   • Properties with values other than the default would be stored in the annotation for the object; properties with default values would not need to be stored, as the value could be determined from the property definition. This is the same logic as with the EMF Extension Model.
2. Embed the JCR Compact Node Definition (CND) representation inside the extended model, replacing the EMF Extension Model reference/import.
   • The extension would utilize namespaced CND property keys
   • Each extended model would contain the definition of the extensions (as defined when the model was created/saved). This can thus be leveraged by other applications (e.g., ModeShape) that consume the file at a later time.
3. Provide feature to convert existing Extension Models into their equivalent CND representations
4. Provide feature to convert existing extended models to the new framework using the CND representation
   • Need to aid users in migrating from old to new framework assuming users have old Extension models.
   • Provide sub-feature to export the CND from model to file in workspace or local file system.
   • Provide sub-feature to apply a selected CND to a model
5. Add validation to flag old extension models and extended models with errors/warnings.
6. Create a CND-driven "Extended Properties" editor, allowing users to view and edit the "extension properties" on objects in extended models.
   • Should support multiple sets of extensions (each in separate namespaces)
7. Replace current Extension Model new model contribution with a CND File builder. This would allow applying same extension properties to multiple models. (Intending on deprecating and eventually removing old EMF-based extension models)

Leveraging existing frameworks

Teiid Designer's use of Datatool's Connection Profile framework has introduced the concept of attaching non-EMF properties to a relational model. This comes in the form of the same name/value properties as used for overriding extension properties. (i.e.  '<tags..... key="xxxxxx" value="yyyy"?>').  The ResourceAnnotationHelper class provides helper methods to add/get/remove properties associated with an annotation object who's reference is the single ModelAnnotation object. Adding CND key/values for each model extension should be fairly straight forward.

Modeshape framework provides both a JCR api and a CND framework that can assist Teiid Designer. This will require a few more Modeshape jar dependencies.

Release Plans

7.4 Release

• Complete 1 thru 5 above
• Create a simple string value property editor in place of 6
• Deprecate old Extension Model framework and models
• Extension Model validation would default to "warnings"

8.0 Release

• Complete 6 and 7
• Disallow old Extension Models. Validation will result in errors.

Notes on Current Framework

The <tags .... /> entries in Designer EMF/xmi files were originally designed to manage Model Extension properties that needed to get indexed so the additional metadata is available on the Server (i.e. Teiid). Until 7.0 Teiid Designer, there was no other mechanism whereby tags could be added to a model.  In 7.0, Teiid Designer embraced the Datatools Connection Profile framework to replace the custom connections of 6.X and legacy MetaMatrix releases. As part of that feature change, Teiid Designer began using the "tags" structure to store connection metadata.

Currently that connection metadata is being indexed as if it were model extension properties.  We will probably need to build into our new Model Extension framework the ability to "filter" tags from the indexing logic (RuntimeAdapter class). Maybe we can expose these filter options as user preferences.

After working on converting our Saleforce model extension into the new framework we've arrived at the following as the proposed Model Extension Definition properties stored on the resource annotation:

Since the Salesforce use-case involves a coded Eclipse contribution, the handler can interpret and map the property names to their tag names. Example would be "salesforce:supportsCreate" == "ext-salesforce:Supports Create"

When users create custom Model Extension Definitions they will be constrained such that the resulting Modeshape CND property names can be auto-generated and mapped more easily.