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.