2 Replies Latest reply on Aug 20, 2014 5:08 PM by Max Rydahl Andersen

    Teiid Designer's Teiid Runtime Client Architecture

    phantomjinx Newbie

      Introduction

      Teiid Designer is a modelling environment for the creation of virtual databases (VDBs) that fuse together different types of information store. The produced VDB files are uploaded to a Teiid instance installed on a running Jboss server.

       

      Interaction with Teiid

      In order to create a VDB, Teiid Designer requires interaction with a Teiid instance in the following ways:

      • Access and display the installed Teiid translators;
      • Access, display and (if necessary) remove existing datasources and VDBs;
      • Upload local VDBs as either completed artifacts or interim previews;
      • Execute uploaded VDBs by connecting to them using the Teiid JDBC Driver and query their fused data.

       

      History of the Architecture

      • The Teiid server used to be an independent entity running under its own port on a computer. As of Teiid version 7, the project sought to integrate the server into Jboss as a set of modules and subsystems. However, the external Teiid client API remained the same.
      • The Teiid project provides a separate runtime client for accessing a Teiid instance. This client is totally independent of Eclipse and Jboss Tools (JBT) and serves as a library that users can integrate into their own projects.
      • Older versions of Teiid Designer used to integrate Teiid's runtime client library as a binary jar into its codebase. However, this had the limitation that only the Teiid client and the same version of the Teiid instance could be guaranteed compatibility.
      • As of version 8.0 of Teiid Designer, the Teiid client began to be forked, with 3 versions of the client being present in version 8.4. This process has proven unsustainable in the long-term and the client has been paired back to a single version that is modified to be backward and forward compatible with each new version of Teiid.

       

      Current Status of the Teiid Client

      Due to the historical evolution of the Designer Teiid runtime client and the requirement to follow Teiid's upstream version, the client's dependencies are a hybrid of nested libraries (auto-downloaded via maven) and Eclipse dependencies.

       

      Teiid Client Eclipse Dependencies:

      • org.jboss.tools.locus.sf.saxon;
      • org.teiid.designer.spi;
      • org.eclipse.core.runtime;
      • org.eclipse.core.resources;
      • org.eclipse.wst.server.core;
      • org.jboss.ide.eclipse.as.core;
      • org.jboss.ide.eclipse.as.management.core;
      • org.eclipse.datatools.connectivity;
      • org.eclipse.datatools.connectivity.ui.

       

      Teiid Client Nested Runtime Libraries:

      • javax.resource.connector-api;
      • org.jgroups.jgroups;
      • org.jboss.as.jboss-as-cli;
      • org.jboss.as.jboss-as-controller;
      • org.jboss.as.jboss-as-controller-client;
      • org.jboss.as.jboss-as-protocol;
      • org.jboss.jboss-dmr;
      • org.jboss.logging.jboss-logging;
      • org.jboss.marshalling.jboss-marshalling;
      • org.jboss.marshalling.jboss-marshalling-river;
      • org.jboss.modules.jboss-modules;
      • org.jboss.remoting3.jboss-remoting;
      • org.jboss.sasl.jboss-sasl;
      • org.jboss.threads.jboss-threads;
      • org.jboss.jboss-vfs;
      • com.googlecode.json-simple.json-simple;
      • javax.transaction.jta;
      • io.netty.netty;
      • nux.nux;
      • org.jboss.xnio-api.

       

      Future Developments

      Increasingly, it is becoming clear that this approach is also unsustainable since the nested integration of Teiid Designer with JBT implies the possible existence at runtime of 2 versions of the same library, eg. jboss-dmr. This can present problems and may even be the cause of lockup issues and other odd behaviour.

       

      For Teiid Designer to properly integrate with JBT, it needs to re-engineer the Teiid client internals to make use of the JBT libraries and framework rather than interfacing at the lower level of communicating directly with the Jboss server. For example, in order to get the client to compile without the nested Jboss libraries, the following classes will need to be modified:

       

      Consideration of Limitations of such Future Development

      • Designer's Teiid runtime client remains largely independent of JBT dependencies. The Komodo branch of Designer has successfully implemented a Teiid client that has no Eclipse or JBT dependencies at all. For the internals of the client to rely on JBT, this would no longer be possible and would necessarily tie the clients future with JBT and eclipse.

       

      Questions for Discussion

      1. How would the Teiid client classes be modified to interface with the JBT API rather than directly with jboss.as?
      2. Should the Teiid client be modified in Teiid Designer to more directly depend on JBT and lose some of its independence?
      3. Could the existing client architecture be preserved to allow for an intelligent client that knows what environment it is running in and use the most appropriate connection mechanism or more simply be broken into 2 clients, a JBT version and a standalone version?
        • 1. Re: Teiid Designer's Teiid Runtime Client Architecture
          Rob Cernich Master

          I believe JBT provides some sort of access to DMR, which may allow you to prune that branch of your dependency tree.  JBT also provides access to the management interface, so that may be an option as well.  This would probably require rewriting your client to use management calls, if they exist.  rob.stryker.old may be able to provide more insight.

          • 2. Re: Teiid Designer's Teiid Runtime Client Architecture
            Max Rydahl Andersen Master

            Before we go an rewrite all I think it would be good to isolate *what* is causing the freeze.

             

            Is it because Teiid Designer is bundling "bad"/mismatched jboss remoting client jars that just won't work properly and can be fixed by simply updating to use an updated set of client libraries ?

             

            Or is it that Teiid Designer simply just do a specific call that triggers a freeze ? i.e. TEIIDDES-2288 is hinting that it is only when external managed is checked, which means server adapter will not actually do any check for if it is running - thus the number and sequence of remoting calls are probably very different.

             

            Now, to give some background for what is in our server plugins then here we try to ensure we use the *smallest* number of client libraries and try to ensure we use the latest supported remoting client libraries which are promised to stay compatible across the broadest number of versions of the server  - while at the same time realizing this might give problems and not always happens..thus we actually fully decouple our calls to the client management api from the actual physical client libraries - allowing us to swap out the client library (somewhat similar to  what you do for teiid designer libs).

             

            I think today we currently only have 2 libs set - one for AS 7.0 and another for AS 7.1 and older (including EAP)...and I think they are the WildFly 8.0 ones since they work with majority. Rob Stryker should be able to confirm that.

             

            But yes, As Rob C. suggests - if you could reduce your calls to the management to simply call out via the as.core provided dmr classes coming from the best matched client library we at least ensure eclipse won't be cross-mixing client libs.

             

            ..but before we start walking that walk I think it is worth establishing *why* the freeze occurs - if it would also happen if you used the exact same client jars we use then we would not actually have solved the TEIIDDES-2288 issue.