Skip to content

Latest commit

 

History

History
56 lines (37 loc) · 3.8 KB

jdv-changes.adoc

File metadata and controls

56 lines (37 loc) · 3.8 KB

JBoss Data Virtualization Developer Guide to Spring Boot based Teiid

As a developer if you are using Spring Boot library with DDL VDB for your Data Virtualization purposes, then guide will provide details about what features are supported when compared to previous versions of Data Virtualization.

Why the changes?

The new model is more suited for the container based workloads in cloud environments like OpenShift. A slim runtime image can be generated for a given VDB such that it can be managed and scaled independently of any other VDB.

Key changes from JDV

  • A single instance of EAP/WildFly with Teiid installed could have any number of VDBs deployed. With Teiid Spring Boot a single VDB is used to build an application instance. If you have multiple VDBs each one needs to be defined using a separate application.

  • There is no installation of a server or deployment of VDBs in the new architecture. You build a docker container that has a single VDB that works as virtualization database. This docker image can be run in OpenShift using maven based build processes, which supports a CI/CD based delivery model.

  • DDL based VDBs are only type that are supported. TIP: If you have a .vdb file, convert that to a single -vdb.xml file using designer. Then convert that file to a .DDL vdb using the VDB migration utility.

  • Each instance of an application will have their own configuration in an application.properties file.

    • Configuration changes will always need to restart the instance.

  • The data source configuration is different from JDV. You will follow the necessary configuration for the relevent Spring Boot component - JEE resource adapters are no longer used.

  • If the application exposes the OData API, the endpoint URL is different from previous versions. The /odata4/<vdb-name> is dropped from the URL.

  • OData API can be secured through Keycloak using OpenIDConnect protocol. The OAuth2 based authorization can be enabled.

  • Monitoring support can be enabled through Prometheus and Dashboard through Grafana.

  • User defined functions and their Java based code can be part of the VDB application or they need to be defined as dependencies to the application in the pom.xml file.

  • Failover and horizontal scaling are natively by OpenShift.

  • All logs, including the Audit/Command logs, are logged by default to the console log.

    • You may change the logging configuration to suite your needs, but in OpenShift additional facitility will be provided for the collection and analysis of logs.

What’s not supported yet

  • Not all sources are supported yet.

  • The internal distributed cache (materialization, resultset cache) is not supported yet.

  • VDB import is not based upon runtime metadata, so its use generally requires VDBs that have all of the metadata fully specified in DDL.

  • Runtime lists from the Admin API - sessions, queries, transactions, etc. will be available via system tables.

  • Data source level security at resource adapter level including the passthrough authentication is not supported. Some features like Kerberos and OAuth2 delegate models will be considered for future versions.

  • No prebuilt scraping of Audit/Command log is provided. ELK/LogStash being considered for future versions.

  • Runtime manipulation of multisource vdb sources

What’s not supported

  • The VDB version concept is not supported.

  • Peer-to-peer clustering

  • The Designer tool to build and test the VDB is no longer supported.

  • XML document models are not supported.

  • Wildfly/EAP runtime is not supported.

    • JAAS based security integration is not supported.

    • Resource Adapters are not supported.

    • No Admin API support. Since the application instance is immutable, the instance started can NOT be modified. Monitoring will utilize JMX and exposure via jolokia or jmx_exporter.

    • Teiid Web-Console is no longer supported.