Feedback on Tefkat

Here’s some feedback on Tefkat that I found in a paper discovered via a persistent Google search for “Tefkat”. I don’t have time to address all the issues right now, but I thought I should post them anyway. I will note that several criticism apply to very early versions of Tefkat and are no longer valid.

The following are the issues with Tefkat that could not be resolved;

  • Not accessible via ant, can not be composed into larger transformation chains.
  • Can not reuse transformation fragments (e.g., no include/import capability)
  • Requires fixed,static set of sources and targets, which are identified in a configuration model.  In practice, provisioning requires an arbitrary and dynamically determined set of sources and targets.
  • Requires explicit tagging of each project with a tefkat nature, plus manual creation and maintenance of a configuration model.   
  • No possibility for incremental target model updates.
  • No possibility for determining scope of incremental source model updates.
  • No default transformations.  For example, a copy of an instance of a source model to an instance of a target model requires a fully elaborated transformation, element by element, containment by containment, association by association, attribute by attribute.
  • Parameterization of transform would only be possible via an additional source model.  Environmental state/properties are not accessible.
  • Use of internal EMF api reduces portability across EMF versions.   Different versions of EMF alter behavior of QVT engine.
  • Extremely poor performance.   Use of multiple elements in a “FOR ALL” may result in exponential number of WHERE evaluations across entire model.
  • No recursively defined templates.
  • Awkward mechanisms for sequencing and/or working around recursion limitations.   For example, trying to determine sequence of a choreography requires temporary information sets and rescanning model to determine and process each successive node.
  • Target instances are generally not acceptable to other processing engines (e.g., bpel, wsdl, j2ee, etc.).  These require xslt transforms to get them into an acceptable state.  This problem is joint tefkat/emf problem.
  • Very limited expression evaluation, there is only simple arithmetic operators and a string concatenation capability.
  • No possibility to produce non-model target artifacts such as java source, text files, etc.
  • No mechanism to include defined “extensions” to models (e.g., an  “any”), such as the bpel extension or technology binding extensions to wsdl.
  • No extension mechanisms to work around any of the other problems.
  • QVT not yet adopted by OMG.
  • Not open source.
  • Provider (DSTC) no longer in business.

Post a Comment

You must be logged in to post a comment.