Skip to main content

JCA Container Integration, Why Teiid needs it? Part 4

Reason # 4 JBoss Microcontainer

JBoss Microcontainer (MC) is at the core of JBoss AS and provides many essential services needed in developing any enterprise software application. Teiid utilizes MC, through several of its key sub-frameworks, to manage services and configuration/deployment artifacts.

Service Framework:

Prior releases of Teiid defined their own service framework(s). These legacy frameworks each had essential flaws - such as not being flexible in defining new services, not providing dependency management, or cumbersome/non-existent configuration management. Teiid in the 6.x releases used "google-guice" for dependency management between services with homegrown configuration management. The service lifecycle was explicitly managed through admin api methods.

MC provides a POJO based service framework with IOC style dependency injection and full lifecycle management. A simple XML based configuration can your POJO based services along with their state and dependencies. As an added bonus this framework also provides persistence services for the configuration. By moving Teiid to MC, we simplified the definition of our services and greatly improved our dependency management - which eliminated the need for Teiid specific configuration framework. Find more information on MC's component model here. And since MC also supports osgi and google-guice, integration of components developed against other IOC frameworks will work together seemlessly.

Deployer Framework:

Teiid requires deployment facilities to handle artifacts such as VDBs, Connectors/RARs, or connector bindings. In prior releases of Teiid deployment and discovery of deployed artifacts was homegrown and based upon different modes of operation - server vs. embedded. This led to inconsistenties in the deployment/discovery code. Dynamic class path management was also led to quite a few issues when JAR resources involved.

MC has the one of the best deployment frameworks with every flexibility you can imagine. As soon as an artifact is visible at a specific location, the deployer service gets notified. This removes the need to write any scanners for detection of artifacts for your application. This framework gives access to the input stream of the resource(s) that are deployed to be consumed by your service. If you are working with JAR or ZIP based resources, the deployment can be defined to check the structure and validity of the resource.

The MC framework provides resources through a Virtual File System (VFS) such that you can replace standard file based deployment with any structured repository if you choose to. With the deployer framework you can also construct a class loader based on the artifact deployed. JBoss AS uses this feature to define WAR class loaders. You can read about class loading here. Teiid was re-written to use this deployer framework to load its VDBs (and any contained UDFs). Connectors were re-written as JCA connectors, which are deployed in JBoss AS using RAR and "-ds.xml" files that already have hooks in the deployment framework.

Management Framework:

Now that we have defined the services and deployed artifacts, how do you manage them during runtime? Teiid in the previous releases exposed specific administrative interfaces for management of certain resource and did not provide any JMX based management. This led to building Teiid specific Management Consoles that worked only with our administrative functionality. Integration into tools such as BMC patrol, HP Open View etc. for the purposes of management was not possible. For Teiid this was one of the *major* reasons to adopt MC.

MC provides a framework to define management interface on your beans through annotations. There is no need to define a MBean interface, yet it works like JMX 2.0 and has more features. JBoss also provides away to expose a JMX interface on your beans simply a providing the @JMX annotation - however this still requires you to define an interface. Teiid has not made use of this JMX feature, but will in subsequent releases.

One thing missing from MC was way to expose the management of your managed beans to external applications. However, JBoss AS luckily comes to rescue by providing the "profile service" through which these beans are exposed. The profile service lets you build your management applications using JOPR based tools. I think development is under way to pull the profile service technology into MC proper in the next release.

Conclusion:

Teiid used MC facilities to re-write its whole management layer. There is simply no comparing the ease with which our services are wired together, configured, and managed with our previous releases. This has created a strong dependency on MC and additional dependencies on JBoss AS. Hopefully this article did a good job highlighting all the benefits of the MC integration. Let's explore the JBoss AS dependency benefits in the next article.

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