Tuesday, February 16, 2010

JCA Container Integration, Why Teiid needs it? Part 3

The Teiid project is being integrated to run inside a JCA container. In earlier posts I gave two compelling reasons for the move.

Reason # 1
Reason #2

Today we examine #3

Reason 3: Security

Security is vitally important for any enterprise application. This is especially true for Teiid as there are typically strict organizational rules governing access to data sources. At a high level Teiid allows for a customizable user authentication/authorization system. There are pre-defined system administrative roles and data authorization roles can be defined for each virtual database (a.k.a. entitlements, or data roles) to govern access at a granular level.

Teiid 6.2 (and earlier) Security Features

Teiid 6.2 provided a Membership API to define customizable security domains from which to obtain authentication and authorization information. Teiid shipped with implementations of LDAP and File based membership domains. Security at the connector level was supported, static credentials, client passed credentials, or through "trusted" payloads. Using trusted payloads, the client can pass any object to a connector for custom authentication/authorization. Like previous issues, this worked great! and there are reams of code to prove it. However, there is a better alternative JAAS.

Java Authentication and Authorization Service (JAAS)

JAAS is a java based security framework that is built into Java runtime. Here is description from the spec site:

Underlying the Java SE Platform is a dynamic, extensible security architecture, standards-based and interoperable. Security features — cryptography, authentication and authorization, public key infrastructure, and more — are built in. The Java security model is based on a customizable "sandbox" in which Java software programs can run safely, without potential risk to systems or users.

JBoss AS uses the PicketLink (JBoss Security) as the security module, which implements the JAAS based authentication framework. Out of the box there are various different login modules available for use. As before, LDAP and File based login modules supported. If their requirements are not satisfied with any of the provided modules, a developer can also write a custom login module.

By moving into container environment Teiid:
  • replaced a custom security framework with a standards based JAAS based framework
  • has access to a plugin based authorization and authentication mechanism
  • retained all the functionality from before to define security domains.
  • reduced its code footprint.
Connectors can also be configured for a "security-domain" such that the container ensures the user is authenticated prior to access. In some Containers this security profile is used to create user specific connection pools to segregate connections from common connection pools. Having this login context available at the Connector is similar to having the "trusted payload" as before, however passing a payload is left for the implementation of the login module.

Next up well look at Microcontiner and its service and deployer framework.

Tuesday, February 2, 2010

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.