Background
Teiid is a federated data integration engine that for a end user looks and behaves like a relational database. However the inner workings of Teiid apart from the optimization engine are much more similar to any enterprise application, such as security, user management, resource management, log management, clustering and transaction management etc.
Over the years Teiid has developed all the above features in addition to our own core IP which is query optimization. One thing to note here is Teiid may not have implemented many of these features in accordance to industry standards. This may be because no such standards existed at the time of development or not seemed important. As these become more popular, users are starting to ask these features like JAAS or high availability more and more. Though we can continue in-house development of these features, we do not have much core IP in developing these features nor resources. In contrast, in our investigation, we found that many of these features are already a standard practice in all of the current day JEE servers. This project is the effort to re-architect the Teiid runtime such that Teiid relies on external containers to provide such functionality, while Teiid resources can focus more on core data integration features.
Goals:
The goals for the Teiid are simple.
1) Run in JEE AS container. Teiid team will focus initially on integrating with JBoss AS version. This will be Teiid Server runtime.
2) User should be able to embed Teiid runtime along with its chosen container in a separate host VM. This will be the “embedded” version.
Requirements:
These requirements are written in terms what Teiid needs from its host container. The design section shows how these requirements can be satisfied.
Requires transaction aware container. Must able to support XA transactions.
Require to execute work in a separate thread.
Provide a standard way to define a data source. Like making connections to Oracle, DB2 etc.
Provide JAAS based authentication, at the top when user logs in and at the bottom for the connector bindings to authenticate themselves with their native systems (trusted payload)
Logging services (preferred)
Caching services (preferred)
Ready availability of the management tools.
Good community for support.
Analysis:
Application server containers such as JBossAS or GlassFish that implement the JCA (Java Connector API) specification seem to provide the required functionality. Please read JCA specification here
Especially, this interface in JCA API
public interface BootstrapContext {
WorkManager getWorkManager();
XaTerminator getXaTerminator();
}
Where a JCA container environment gives access to thread pooling and access to XA terminator using which a XA transaction can be managed. With the availability of this interface, Teiid engine can be wrapped into a JCA connector, where it can continue using multi-threaded processing and also it can lease out the transaction management to the container.
public interface javax.resource.spi.ManagedConnectionFactory extends java.io.Serializable {
public ManagedConnection createManagedConnection(
javax.security.auth.Subject subject,
ConnectionRequestInfo cxRequestInfo) throws ResourceException;
..
}
The above interface provides the 'Subject' to the JCA connection, thus if container supports JAAS based authentication then it will pass logged in user's credentials up to a JCA based connector for its use. JBossAS does support JAAS based login with their security domains.
JBossAS does provide JOPR and admin-console based tools for management. Hooking Teiid management into these tools would be ideal.
The current Teiid Connectors API has borrowed concepts from JCA and JDBC API. Teiid runtime then provides the needed connection pooling for the connectors. Teiid also invented concept of “extension modules” to support the dynamic loading of the Connectors, then invented the CAF file format to combine the configuration and dependent extension jars. However, there are still the issues around the connector that are plagued with challenges for future. See TEIID-143 (https://jira.jboss.org/jira/browse/TEIID-143)
Instead of borrowing the concepts from JCA for the connector API, if we extend the JCA API with the Connector API then Teiid connectors can be re-written as JCA connectors and can be deployed into any JCA container, where the life cycle management is is completely documented and supported through JCA API.
A Teiid runtime also requires configuration to external “data sources” through Connector Bindings. A Connector Binding instance is essentially
Connector Binding = Connector specific configuration + (Optional) Data source configuration
Connector specific configuration, defines the capabilities of a Connector. Where as Data source configuration contains connection information to a data sources such as user id, password and host information. Teiid always struggled with keeping this information toghether. The format these values stored are very specific to Teiid deployments. By using container environments, how to define a data source configuration is fully defined by the containers and most users have familiarity in defining these, so there is much to gain from this developer knowledge in defining a connector binding.
The JCA components are packaged in RAR file format, which specifies how the configuration needs to be defined and how dependent library files need to be specified under a single file(thus no extension jars). The JEE model also defines how a RAR file should be loaded into separate class loaders in the containers, thus relives Teiid from managing home grown mechanisms of class loader hell.
Each JCA based Connector will be a independent module that can be discovered in a container environment though JNDI lookup. This means that a VDB artifact can refer to a Connector through a JNDI name and associate with it, at the same time the configuration for that connector is managed external to the VDB artifact itself, which is much desired for switching the VDB from development time artifact to runtime artifact.
Connectors as JCA also opens up a huge opportunity in supporting wide variety of data sources. Most of the EIS (enterprise information systems) do provide a JCA based connectors to be used with JEE environments. A motivated user can wrap Teiid Connector API around these JCA connectors and provide Teiid specific relational abstraction then use them in Teiid data integration project. For example if there is a SAP based JCA connector, some one could use that and extend to use with Teiid.
The below diagram features some of the differences between the current model and proposed future model.
Implementation:
General:
JBossAS Server will be used for the Standalone server environment.
JBossAS Embedded will be used for the Embedded runtime scenarios.
JBJCA project will be evaluated to be used in the Embedded environments in future where a light weight container is needed. After the JBossAS 6.0 is released.
Current kit will be removed, and one that can be readily deployed on top of a JBossAS or JBossAS Embedded will be supplied.
Connectors:
Connector API will be extended to implement JCA API, all the base classes that implement JCA will be provided for the user.
All the Teiid connectors will be changed to new JCA based connector API
All Teiid Connectors will be packaged in RAR file format.
Since connectors have life cycle of their own, the centralized “configuration.xml” file will not be supported. That means the bindings and type information will not be stored in one central space.
The binding information need to be supplied in “xxx-ds.xml” file that defines a ConnectionFactory/Datasource in JBoss environment. (this will be different in other containers)
Since the physical data source information like connecting to Oracle is different from Connector information, if there is a data source (in the cases of JDBC) that information will be stored in its own “xxx-ds.xml” file apart from the connector's “xxx-ds.xml” file. The connector's file will contain the JNDI name of the data source, so that the connector knows to make the connection.
There will be no “connector types”. JBossAS will be able to list available Connectors in a container and list required properties, those should be defined in Connector's "xxx-ds.xml" file.
There will be no “extension” modules. RAR file will contain all the dependencies.
If the dependent jar can not be placed inside the RAR file then it needs to be supplied “lib” folder of the container. The dynamic loading of this jar is questionable. Containers do allow this, not sure with the JBossAS.
When SOAP connectors externalize their connection, then they will operate same way as the JDBC connectors and get full capabilities like SAML support if container supports it.
Engine:
The Teiid engine itself will be converted to a JCA connector.
Currently “Guice” is used for DI, we still keep this, moving to depend on MC based DI will be evaluated as stretch goal.
The “deploy.properties” file will be replaced with “teiid-runtime-ds.xml” file to provide the configuration needed by the engine.
This engine JCA component will also start a Socket listener to accept the socket based connections in the Server environment.
Transaction management will be re-written such that they are handled by the container's Transaction Manager.
In the case of “Local Transaction” and “Request Transaction” the Teiid engine JCA will invoke and terminate the transaction. It invokes by creating XID for the transaction that will be then be imported into container's Transaction Manager, and this module will manage the “commit” and “rollback” calls.
In all the transaction scenarios, when a XA data source is participating in the transaction, then the container's Transaction Manager is managing the enlisting and delisting of sources in a JTA transaction.
Engine will preserve the multi-threaded execution of process worker threads and connector worker threads by using WorkManager based thread pool.
Connector initialization will not use any specific use of any class loaders. They will be looked up in the JNDI tree based on the name supplied to them through VDB configuration.
User Management:
Current Membership Domain will be replaced with JAAS based membership service.
Current File, LDAP based Membership domains will be removed.
Authorization service will be fitted with new JAAS based membership.
Currently the group assignment to admin-roles is done by the Teiid, this could possibly moved as the functionality of the container.
Admin API:
All the “extension jar” specific calls be removed
All the “CAF” specific calls will be removed.
All Connector type specific calls be removed.
All connector specific calls are debatable for their existence as they can be managed directly through the container.
Connection Pool statistics will be removed, they will be available from container.
Management of system properties is shifted to the engine's JCA property management.
Similar to JBossAS profile service, a similar service need to be defined for the Teiid to manage the rest of the Admin API based methods.
JDBC Driver:
The “embeeded” URL will change, there will no need to specify the “deploy.properties” it will be just “jdbc:teiid:<vdb-name>”.
No change for for Server mode.
Concerns:
The biggest concern is the Designer tool integration. With the DTP integration going on, this need to evaluated as how this changes can be accomplished. If Designer would have depended upon the published external interfaces like JDBC API and Admin API the challenges would have been much more easily manageable.
Management of logging contexts.
Creation of XID can produce a duplicate value in an extreme situations. This can avoidable with some custom code for the each container.
Comments