Skip to main content

JCA Container Integration, Why Teiid needs it? Part 2

Continuing from our earlier discussion "JCA Container Integration, Why Teiid needs it? Part 1", here we will discuss the next reason.

Reason 2: JCA API

What is the JCA API?

From the spec site (J2EE Connector architecture): JCA defines a standard architecture for connecting the J2EE platform to heterogeneous EIS systems. Examples of EIS systems include ERP, mainframe transaction processing, database systems, and legacy applications not written in the Java programming language. By defining a a set of scalable, secure, and transactional mechanisms, the J2EE Connector architecture enables the integration of EISs with application servers and enterprise applications.

What is a Teiid Connector?

Teiid connectors also connect to heterogeneous EIS systems, but they implement a Teiid specific Connector API to:
  • Consume commands from the Teiid engine in SQL command object form and translate them into native commands to query and update enterprise sources.
  • Deliver resultant data in a tabular or XML format to the Teiid runtime engine.
  • Provide metadata on what SQL constructs and command forms are supported by the connector.
How is a Teiid 6.x Connector similar to a JCA Connector?

In many ways Teiid connectors are similar JCA connectors.
  • The Teiid connector API has many borrowed concepts from JCA API and JDBC API.
  • A Teiid connector can be developed to any EIS to access data.
  • Teiid connectors are packaged in Teiid specific Connector Archive Format (CAF) and deployed into Teiid runtime.
  • Teiid Connector's configuration metadata was defined in special XML file called "configuration.xml" called Connector Type.
  • The connector's runtime properties are defined in another XML file called Connector Bindings.
  • Teiid runtime provides connection pooling for the Connector connections
  • Connector connections can optionally be pooled and participate in XA transactions.
All this worked well, however JCA connectors provide similar functionality in a standard way. By replacing Teiid Connectors with JCA connectors a lot of duplication in concepts and code are avoided.

Benefits of the JCA API with Teiid
  • Provides standards based feature rich API for developing connectors. Teiid only needed to define extensions to this API to provide Teiid specific functionality.
  • Standard packaging structure. JCA provides a RAR file format, which can embed all the resources specific to this connector in a single artifact. This replaces the non-standard Teiid CAF file.
  • Defines a class loading scheme for RAR files that solves common class loading issues involved in Teiid connector deployment. The old CAF file did not define a classloading scheme, but relied on "extension" modules.
  • Provides a standard way to define the connector's configuration medata in a "ra.xml" file. This eliminates the need for defining connector types in Teiid.
  • Availability of various JCA containers like JBoss AS to deploy your connectors.
  • JCA provides support for participating in Local and XA transactions.
  • Built in support for various security concerns.
  • Developer familiarity.
Previously functionality like configuration, depolyment, runtime management, connection pooling and transactions support was provided by the Teiid runtime. Now as a JCA connector, the JCA container (like JBoss AS or even GlassFish) provides a similar feature set.

Benefits of a JCA Container
  • A standard deployment model across containers. Containers know how load these connectors into separate class loaders defined by the J2EE spec. There is no need for "extension" modules in Teiid runtime to load dependent JAR files into system.
  • Built in connection pooling by container. Teiid's connection pool, while optimized for performance, is not as feature full as those offered by a container.
  • Container defined deployment model. For example JBoss AS defines a xml file format "-ds.xml" to configure runtime properties of this connector. Previously Teiid defined it's own XML format to define the connector binding.
  • Access to container management tools to configure, deploy and manage connectors. Teiid specific management is not required.
  • Access to a wide variety of JCA connectors for different EIS sources by different software vendors. These can be easily extended to use with Teiid thus increasing Teiid's ability to integrate more sources.
  • Variety of JCA containers to choose from, like JBossAS, GlassFish, WebSphere, etc.
  • Developer familiarity. If you know how configure a data source under container, you will understand how to configure a Teiid connector.

The Teiid Engine with JCA

The Teiid engine itself is also being developed as a JCA connector. While the engine does not directly connect to EIS, it still needs access to standard functionality provided by the JCA API.

XA Transactions:

The Teiid 6.x runtime provided transaction support using an embedded instance of JBoss TM. Even though Teiid used an external transaction manager, coordinating XA transactions is a complicated task especially in a multi-threaded multi-source environment like Teiid.

By using a JCA container as the runtime environment these tasks are delegated to the container, and since the JCA API provides access to the "XATermintor" interface, Teiid can still control the start/commit/rollback of transactions initiated through our JDBC client. Now the Teiid runtime does not explicitly depend on a particular transaction manager.

Multi-Threaded Environment:

The Teiid runtime is a multi-threaded environment with specialized queues to ensure highly parallel processing. Our processing model was also easily adapted to the JCA API, since it provides access to the "WorkManager" interface that fronts a container managed thread pool.

The article shows that the JCA standard was the gateway to integrating Teiid into a container, but it is only a start. We'll cover security in the next article, stay tuned.

Comments

Popular posts from this blog

Teiid 8.11 Beta1 and 8.10.1 Released

Teiid 8.11 Beta1 is now available from the  downloads  and maven.  Feature highlights since Alpha2 include: TEIID-3434 More caching control over ttls in the result set cache down to the schema/table level. TEIID-3412 MS Access support via the UCanAccess driver. The UCanAccess support is necessary for those running on Java 1.8 as the JDBC ODBC bridge has been removed from the JRE. The waiting continues on EAP 6.4 Alpha1 - it still should be available shortly and should be the platform target for Teiid 8.11 Beta2. Of course, let us know if you find any issues with these early releases.  There's still plenty of time to get fixes into the final release. Teiid 8.10.1 is also available.  It addresses 5 important issues discovered since 8.10 was released: [ TEIID-3409 ] - PostgreSQLExecutionFactory TranslatorProperty annotation in wrong place [ TEIID-3437 ] - Inconsistencies with row count handling [ TEIID-3438 ] - Null value returned from BlobImpl

Tech Tip: Teiid SQL Language MAKEDEP Hint Explained

In this article I will explain what a MAKEDEP hint is, how and when, why it should be used in Teiid. What: MAKEDEP is query hint.  When a query hint is defined in the SQL query it influences the Teiid query planner to optimize the query in a way that is driven by the user. MAKEDEP means "make this as a dependent join". What is a Dependent Join? For example if we have query like: SELECT * FROM X INNER JOIN Y ON X.PK = Y.FK Where the data for X, and Y are coming from two different sources like Oracle and WebService in Teiid, so in relational algebra you can represent above query as Here the result tuples from node X and node Y are being simultaneously fetched by Teiid query engine, then it joins the both the results inside Teiid engine based on the specified X.PK = Y.PK condition and returns the filtered resulted to the user. simple.. Now, what if, if X table has 5 rows and Y table has 100K rows? In order to do the JOIN naively Teiid need sto read all the 5

Teiid Spring Boot 1.7.0 Released

Teiid Spring Boot version 1.7.0 to support Teiid 16.0 has been released. This release is mainly to support the Teiid's latest version.  In this release, the support for OpenAPI code generation based on VDB has been removed as there is no community interest and moreover it was at OpenAPI 2.0, and the industry has moved to 3.0 and beyond. There are no plans to further pursue this feature. VDB maven plugin was also removed, which was intended to be a replacement for the VDB importing feature was to be used when working on OpenShift, however, since it requires the Maven repository and does not completely represent the feature as defined on the WildFly based deployments this is also removed. You can still use the VDB import feature with Teiid Spring Boot, simply define the VDB with your "IMPORT DATABASE" statements and provide the additional files along with the main VDB file. During the start of the application, Teiid Spring Boot will load all the necessary DDL files for the